Skip to content

OLGModel14: tighten GE constraints#12

Open
MichaelTiemann wants to merge 7 commits intovfitoolkit:mainfrom
MichaelTiemann:OLGModel14-new-GE
Open

OLGModel14: tighten GE constraints#12
MichaelTiemann wants to merge 7 commits intovfitoolkit:mainfrom
MichaelTiemann:OLGModel14-new-GE

Conversation

@MichaelTiemann
Copy link
Contributor

More, better, faster GE by removing r and Lhscale from the list of GE prices, and then making better use of the GE prices we do have in terms of guiding the return functions. Also, shrink and reshape the grids for better performance as well.

Discussion here: http://discourse.vfitoolkit.com/t/general-equilibria-and-pricing-tensions/593

Create a GE condition that helps the solver nudge wages to help `L_h` and `L_f` find balance.  This also allows us to set `Lhscale` to a more accurate GE balance point without that very setting upsetting the wage equilibrium number so much that our labor constraints never do find a good balance.

Also fix sizes of grids, that were too aggressively sized down (and might yet still be, but more testing is needed to tell).
Increasing the household and firm shares and capital holdings grids from 101 to 201 points yielded an increase in agreement in the final value of each others values.

With 101 grid points, we saw 0.65 vs. 0.85, a 30% discrepancy.
With 201 grid points, we see 113 vs. 117, a 3.5% discrepancy.
Surely this was meant to be 50%, not 52%.
The previous version of this function had the defect that as `w` approached 1, it would return zero, regardless of the relationship of `L_h` and `L_f``.  This new version fixes that defect while maintaining its continuous nature.
Deleting `OLGModel14_GE_wages.m` and related function because it's actually redundant with existing `GeneralEqmEqns.labormarket` function.  The existing function may do better with a larger weight associated (since it influences the `w` parameter, which in turn influence both labor supply and demand).  But we will leave that for others to decide.
After studying why my agents were so impoverished, I realized that Lhscale was doing them no favors at all. The one place where Lhscale is needed is when relating L_h to L_f (and perhaps in government taxation functions).  But the households don't need it and it only confuses things, especially when we are trying to budget for w=1 and we need to fit things like 0.3 for rent.  An Lhscale value of 0.21 inside the consumption function destroys that, pure and simple.
This also has the happy(?) effect of restoring `beta` to a value less than 1 (which the comment seemed to expect would be more correct).

Here's what the GEq finally looked like:

```
Current GE prices:
	pension:   0.3999
	AccidentBeq:   0.0201
	G:   0.0447
	w:   1.0228
	firmbeta:   0.9516
	D:   0.2050
	P0:   1.1897
Current aggregate variables:
	L_h:   0.1808
	S:   1.0013
	PensionSpending:   0.0614
	PayrollTaxRevenue:   0.0370
	AccidentalBeqLeft:   0.0140
	CapitalGainsTaxRevenue:  -0.0246
	Output:   0.2792
	L_f:   0.1774
	K:   0.3599
	DividendPaid:   0.2027
	Sissued:   0.1513
	CorpTaxRevenue:   0.0266
Current GeneralEqmEqns:
	sharemarket: 0.001347
	labormarket: 0.003368
	pensions: 0.024378
	bequests: -0.006375
	govbudget: 0.001803
	firmdiscounting: 0.010416
	dividends: 0.002340
	ShareIssuance: 0.028331
	CapitalOutputRatio: -0.001393
Warning: The permanent type mass weights must sum to one (PTypeDistParamNames points to weights that do not sum to one)
> In StationaryDist_Case1_FHorz_PType (line 56)
In OLGModel14 (line 301)
LifeCycleProfiles_FHorz_Case1_PType: Ignoring the 2-th PType, firm because it is infinite horizon
Following are some aggregates of the model economy:
Output: Y=    0.28
Aggregate TFP: Y=    1.18
Capital-Output ratio (firm side): K/Y=    1.29
Total asset value (HH side): P*S=    1.31
Total firm value (firm side): Value of firm=    1.03
Consumption-Output ratio: C/Y=    2.92
Government-to-Output ratio: G/Y=    0.16
Wage: w=    1.02
Elapsed time is 1042.895036 seconds.
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant